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Procede de verification fonctionnelle d'un modele de circuit integre 
pour constituer une plate-forme de verification, equipement emulateur 

et plate-forme de verification. 

La presente invention concerne un procede de verification 
5 fonctionnelle d'un modele logiciel d'un circuit integre pour constituer une 
plate-forme de verification et la plate-forme de verification ainsi constituee. 

L'invention s'applique, d'une part, tors de la phase de verification de la 
conception des specifications particulieres d'un circuit integre repondant aux 
besoins d'un industriel utilisateur, usuellement appele ASIC (Application 
10 Specific Integrated Circuit), mais, egalement, dans la phase de mise au point 
de I'ensemble constitue par le composant physique ASIC et le programme 
d'application execute par TASIC composant physique. 

Dans le domaine des circuits integres, il existe deux types de circuits, 
les circuits dits classiques et les circuits specifiques dits ASICs. Les 
15 fabricants de circuits integres classiques presentent des catalogues de 
circuits standards dont les references designent chacune une fonction 
particuliere normalisee. Pour des applications specifiques, I'industriel 
utilisateur de circuits integres prefere faire developper des circuits 
specifiques dits ASICs. 
20 Les differentes etapes de developpement des ASICs sont les 

suivantes : 

- definition d'une specification fonctionnelle ; 

- modelisation (definie ci-apres) en un langage de type HDL de 
description materielle de I'ASIC et verification fonctionnelle de la 

25 conception associee a cette modelisation ; 

- fabrication technologique par le fondeur de circuits integres ; et 

- mise au point materielle du circuit. 

La definition de la specification fonctionnelle est : Telaboration des 
documents decrivant les fonctionnalites couvertes par I'ASIC. 
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Elle comprend : 

• d'une part, les specifications de niveau systeme decrlvant : 

- la visibilite fonctionnelle des registres de TASIC ; 

- le protocole de coherence assurant I'integrite des donnees, dans 
5 le cas d'un systeme a memoire partagee ; 

- les specifications des interfaces externes des composants ; 

• et, d'autre part, les specifications decrivant les choix d'implementation 
de TASIC. 

La modelisation de type HDL de TASIC consiste en la description des 
10 equations logiques booleennes rendant compte de son comportement 
conformement a sa specification. Le langage de type HDL utilise est un 
langage dedie a la description des objets materiels du circuit integre 
(Hardware). II contient les primitives de description des composants avec 
leurs signaux d'interface ainsi que des elements memorisant, tels que 
15 registres ou memoires. 

Le niveau de description de type HDL sert de point d'entree au 
processus de generation automatique aboutissant in fine a la fourniture de 
masques pour le processus technologique de fabrication du circuit. 

La verification fonctionnelle de la conception de TASIC a pour objectif 
20 de verifier la conformite du comportement du modele de type HDL de TASIC 
a sa specification fonctionnelle en amont du lancement du processus 
technologique. 

Une fois la logique de TASIC stabilisee, un processus quasi- 
automatique applique a la description de type HDL de TASIC permet de 
25 generer la liste des cellules physiques constituant TASIC et d'elaborer les 
masques livres au fondeur (fabricant d'ASIC) pour la fabrication du circuit. 

La fabrication technologique du circuit est le processus chimique 
permettant, a partir des masques, de produire les echantillons physiques des 
circuits. 

30 Des tests non fonctionnels sont appliques en sortie de fabrication pour 

valider que le processus technologique s'est bien deroule, et selectionner les 



3945AJS 



echantillons bons candidats a etre montes dans les boTtiers pour la phase 
suivante de validation. 

La mise au point materielle est la premiere phase de validation des 
ASICs dans leur environnement systeme reel apres montage des 
5 echantillons dans les boitiers et connexion sur les cartes. 

Au stade de la fabrication, le fabricant d'ASIC n'est pas en mesure de 
verifier que le modele fonctionnel de TASIC fourni par I'industriel utilisateur ne 
comportait pas d'erreur de conception. II est simplement en mesure de 
confirmer la conformite de la puce de silicium avec le schema fonctionnel 
10 demande. 

Un des buts de I'invention est de permettre a rindustriel utilisateur de 
TASIC, avant la realisation physique du circuit, de verifier I'exactitude du 
modele fonctionnel qu'il va fournir au fondeur (fabricant d'ASIC). 

Compte tenu du cout eleve d'etude de I'ASIC, 11 faut valider le plus 

15 completement possible le schema theorique resultant de la specification 
fonctionnelle pour eliminer toute erreur subsistante avant de lancer I'etude du 
dossier de fabrication de I'ASIC par le fondeur. C'est pourquoi le niveau de 
description du modele de I'ASIC est utilise pour la verification fonctionnelle 
de la conception de I'ASIC en amont du lancement du processus 

20 technologique de fabrication. La verification a pour objectif de verifier la 
conformite du comportement du modele de type HDL de I'ASIC a sa 
specification fonctionnelle. 

Avec la complexite croissante des ASICs liee a leur haut degre 
d'integration et le cout eleve de leur fabrication, la verification fonctionnelle 

25 pendant la phase de conception du circuit occupe une place preponderante 
(plus de 60%) qui tendra a s'accroitre encore de fagon notable dans les 
annees a venir. 

D'ou la necessite de disposer d'une methodologie solide de 
verification fonctionnelle. 
30 C'est dans ce contexte que se situe Tun des interets de invention 

proposee. 
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Lorsque des echantillons de I'ASIC composant physique ont ete 
fabriques, Tindustriel utilisateur valide la fonctionnalite de rensemble ASIC 
composant physique-programme d'application execute par I'ASIC et verifie 
qu'ils repondent au cahier des charges de I'ensemble. Au cours de cette 
5 phase, les ASICs montes dans leurs boTtiers sont connectes sur leur carte a 
leur environnement systeme reel pour constituer une plate-forme de 
validation. 

L'invention proposee peut egalement trouver son application dans 
cette phase. 

10 Pour verifier fonctionnellement les diverses parties constitutives du 

modele de I'ASIC, telles qu'unite arithmetique, memoires, compteurs, logique 
combinatoire, routeur a antememoire et autres, on peut les activer 
separement, dans la mesure ou chacune est directement accessible depuis 
les entrees/sorties simulees de I'ASIC et suffisamment independante des 

15 autres. On verifie alors que la partie consideree est conforme a un modele de 
fonctionnement logique defini au cahier des charges. II faut aussi verifier 
I'interfonctionnement des diverses parties, en activant simujtanement 
plusieurs de ces parties. II faut en particulier effectuer des tests 
combinatoires entre les parties pour tenter de verifier Tabsence de 

20 configurations, non prevues lors de la conception du modele fonctipnnel, 
d'etats des diverses parties respectives, qui seraient susceptibles de 
conduire a un fonctionnement defectueux, par exemple un blocage mutuel 
entre deux parties. II est aise de comprendre que le nombre des tests 
combinatoires croit done beaucoup plus rapidement que le nombre de 

25 circuits ou transistors de TASIC. En outre, la presence de memoires dans 
I'ASIC, qui peuvent commander certains des circuits de celui-ci, enframe le 
fait que Tetat global des diverses sorties, pour des entrees presentant un 
meme etat global a un instant determine, depend de I'historique de la 
succession des etats d'entree precedents. 

30 La mise au point de la programmation de tests fonctionnels est longue 

et coCiteuse. En pratique, cette mise au point s'effectue en utilisant le modele 
de I'ASIC. En d'autres termes, des que le modele est congu, on peut alors 
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chercher a detecter les deux types d'erreurs suivants : les erreurs residuelles 
du cahier des charges, et les erreurs ou lacunes des programmes de 
validation fonctionnelle de I'ASIC ou des programmes applicatifs. Ce cumul 
de taches reagissant les unes sur les autres, est evidemment lourd a gerer, 
5 et 11 entraine des couts et des retards. 

La presente invention vise a limiter un ou plusieurs de ces 
inconvenients. 

A cet effet, I'invention concerne tout d'abord un procede de verification 
fonctionnelle d'un modele logiciel d'un circuit integre a la demande (ASIC), 

10 en langage de bas niveau (tel que par exemple de type HDL) traitant de 
fagon separee I'etablissement du modele et la mise au point des tests de 
verification fonctionnelle a appliquer au modele du circuit pour constituer une 
plate-forme de verification comportant les deux etapes suivantes : 

- constitution d'un emulateur autonome de circuit obtenu en 

15 remplagant le modele en langage de bas niveau (de type HDL) de description 
physique du circuit en projet a valider, par une description abstraite de haul 
niveau (par exemple C"*"^) generant des structures de donnees de reponse 
conformes a la specification fonctionnelle du projet en fonction des stimuli 
regus, ce mode etant dit « mode emission », 

20 - integration du modele logiciel en langage de bas niveau (de 

type HDL) du circuit resultant du projet dans la plate-forme de verification, et 
branchement de la configuration de simulation autonome, precedemment 
validee, en parallele sur les interfaces du modele logiciel du circuit, et du 
branchement d'un emulateur d'environnement, et 

25 - utilisation de plate-forme comme reference pour la validation 

des donnees de reponses emises par le modele logiciel du circuit, ce mode 
etant dit « mode verification ». 

Le programme de validation de fonctionnalite peut ainsi etre mis au 
point en temps masque, en parallele avec {'elaboration du dossier de 

30 fabrication de I'ASIC. Ensuite, un modele de ce dernier ayant ete elabore, il 
suffit de disposer en memoire de la sequence d'entree de test de validation 
de fonctionnalite, puisque Temulateur represente la specification 
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fonctionnelle et fournit les stimuli de sortie en reponse a cette sequence 
d'entree, a titre de reference. 

L'emulateur constitue ainsi, fonctionnellement, une sorte de 
bibliotheque qui contiendrait tous les etats de sortie possibles du modele de 
5 TASIC, predits d'apres les reponses de la specification fonctionnelle a tous 
les stimuli d'entree possibles fournis par un emulateur d'environnement. La 
fourniture de stimuli d'entree par Temulateur d'environnement equivaut a un 
adressage du contenu de la bibliotheque pour selectionner Tetat ou stimuli de 
sortie correspondant predit. Cette bibliotheque pourrait done etre une simple 

10 memoire, constituant une table de decision contenant la totalite des etats de 
sortie predits, adressee pour decider que Tun de ses etats est celui qui 
convient. Toutefois, la taille memoire necessaire serait en general excessive, 
et il est alors preferable d'elaborer en temps reel la prediction des stimuli de 
sortie, d'apres la specification fonctionnelle. 

15 II est a noter que le precede de invention n'est pas limite a des ASICs 

purement numeriques, car on peut emuler des circuits analogiques, le cas 
echeant, au moyen d'une unite de calcul numerique et d'un convertisseur 
numerique / analogique. 

Dans un mode de mise en oeuvre, un utilisateur elabore, au moyen 

20 d'un systeme de traitement de donnees, la configuration de simulation 
autonome correspondant au modele logiciel de TASIC au moyen de la 
specification fonctionnelle, 

• Tutilisateur ecrit, a partir de la specification fonctionnelle, et memorise, 
dans une plate-forme de test de modeles de circuits integres, un 

25 programme de test du modele de I'ASIC, comportant des sequences 

de stimuli d'entree a fournir au modele logiciel de I'ASIC, auxquelles la 
configuration de simulation autonome fait correspondre, en fonction de 
la specification fonctionnelle, des sequences de stimuli de sortie, 

• Tutilisateur relle ensemble, et active, la configuration de simulation 
30 autonome et la plate-forme de test, et 
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• il observe les stimuli de sortie du modele de type HDL de I'ASIC pour 
valider fonctionnellement Tensemble constitue par le modele logiciel 
du circuit ASIC et le programme de test de validation, et ainsi valider 
le modele logiciel par rapport a la specification fonctionnelle. 
5 Avantageusement, la configuration de simulation autonome 

communiquant avec I'utilisateur pour commander I'activatlon de modeles, 
prealablement etablis et memorises, de sequences de stimuli d'entree definis 
dans un langage de programmation de haut niveau, et commande I'activatlon 
de programmes associes de validation progressive de sequences de test 
10 determlnees a partir des modeles. 

Grace a la modularite du systeme et a la progressivite de la mise au 
point, I'utilisateur peut ainsi s'appuyer, au depart, sur des modeles de test de 
validation fonctionnelle existants, a priori au point, qu'il complete ou adapfe 
au cas particulier de I'ASIC. 
15 L'utilisateur peut ecrire et fournir la specification fonctionnelle dans un 

langage de programmation de bas niveau, specifiant des modeles 
fonctionnels de circuits. 

II peut aussi, dans un mode mixte, fournir la specification fonctionnelle 
sous la forme d'un programme en langage de bas niveau, de modeles (de 
20 type HDL) fonctionnels de circuits, et d'un programme en langage de haut 
niveau, de modeles fonctionnels ((C++) symboliques de circuits), et 
commander la configuration de simulation autonome (1) pour effectuer une 
co-simulation par synchronisation d'execution des deux programmes de 
specification. 

25 Les diverses parties de la specification fonctionnelle peuvent ainsi etre 

ecrites dans le langage qui convient le mieux, et en particulier qui evite les 
pertes de temps pour definir les stimuli de sortie. 

Avantageusement, la plate-forme de test verifie que les reponses du 
modele logiciel de TASIC sent situees dans des plages de temps de reponse 
30 specifiees dans la specification fonctionnelle. 

Linvention concerne aussi une plate-fomne de verification de modele 
logiciel de circuit integre a la demande, caracterise par le fait qu'elle 
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comporte des moyens de traitement de donnees permettant a un client de 
selectionner des modeles de test engendrant des stimuli d'entree de I'ASIC, 
ces moyens de traitement etant agences pour lire des elements de 
specification fonctionnelle de I'ASIC, et comportant des programmes 
5 agences pour elaborer un programme de test de validation fonctionnelle 
constitue de stimuli de sortie a partir des stimuli d'entree et des elements de 
specification fonctionnelle. 

Avantageusement, la plate-forme de verification comporte une 
bibliotheque de modeles fonctionnels de blocs de circuits pour ASIC et des 
10 moyens de selection des modeles par un fichier de definition de la 
configuration, pour constituer un modele correspondant a la specification 
fonctionnelle de I'ASIC integre a la definition de son environnement. 

II peut y etre prevu, dans une liaison le reliant au client, deux circuits 
en serie d'adaptation de langage de programmation agences pour 
15 transfomrier des commandes en langage de haut niveau (C^""), utilise par le 
client, en commandes en langage de bas niveau (de type HDL), exploitables 
par le modele de I'ASIC, et pour, respectivement, retransformer les 
commandes en langage de bas niveau en commando en langage de haut 
niveau. 

20 Avantageusement, la plate-forme de verification comporte des moyens 

d'executer ses traitements en meme temps que la simulation qu'elle peut 
interrompre des la detection d'une erreur au moment meme de I'apparition 
de I'erreur. 

Selon une autre particularite, les elements de specification 
25 fonctionnelle sont constitues d'une table de verite, ou de comportement, 
correspondant aux fonctions des diverses parties ou divers elements de 
circuit fonctionnels du modele logiciel de I'ASIC, et des plages de retard de 
propagation a respecter entre chaque entree et chaque sortie. 

Selon une autre particularite, la plate-forme de verification dispose 
30 d'une antememoire pour memoriser les blocs utilises par les noeuds d'apres 
leur adresse et des moyens de gerer, pour une adresse utilisee par un ou 
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plusieurs noeuds, un vecteur de presence avec un temoin de presence par 
noeud. 

Selon una autre particularite, las programmes sont orientes objet et 
I'emulateur est structure en un ensemble de classes permettant de gerer une 
5 collection d'hypotheses d'execution d'une transaction sur un bloc memoire du 
modele logiciel, et de gerer egalement les transactions en collisions, c'est-a- 
dire utilisant un meme bloc memoire. 

Selon une autre particularite, les algorithmes des programmes de 
Temulateur realisent les fonctions suivantes : generation des predictions, 
10 d'elimination des predictions, re-ajustement de mauvaise prediction, 
reduction du nombre d'hypotheses valides et terminaison de collisions. 

Selon une autre particularite, la plate-forme de verification est utilisee 
en emulateur de circuit routeur, de circuit a antememoire ou de circuit routeur 
a antememoire. 

15 Selon une autre particularite, la plate-forme de verification permet de 

tester un modele logiciel de circuit integre a la demande (ASIC), caracterisee 
en ce qu'elle comporte un emulateur d'ASIC pour commander un 
comparateur prevu pour recevoir des valeurs generees par le modele logiciel 
de circuit ASIC teste, sur reception de stimuli envoyes par au moins un circuit 

20 generateur de stimuli, memorisant le programme de test, une interface de 
traduction des stimuli d'uh langage elabore vers un langage de bas niveau 
correspondant a celui du modele logiciel, et des moyens de validation de la 
verification en cas de detection de collision par le comparateur. 

Dans une forme de realisation, les moyens de selection de la reponse 

25 a des stimuli dependants de la constitution des circuits testes sont constitues 
d'un modele elabore grace a des moyens de selection, parmi une 
bibliotheque, de modeles fonctionnels associant, a chacun des modeles, les 
reponses a un stimulus donne, le modele correspondant a la constitution du 
circuit a tester. 

30 La plate-forme peut comporter des moyens de memorisation des 

reponses ainsi selectionnees pour constituer un modele de test a appliquer 
au circuit teste lors de la reception de stimuli. 
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Selon une autre particularite, chaque transaction est constituee, au 
niveau de cliaque interface, d'un paquet requete et d'un ou plusieurs paquets 
reponses associes, dont les valeurs des parametres et/ou las contraintes 
temporelles d'emission des paquets peuvent etre forcees a partir du 
5 programme de test fonctionne! execute par Temulateur de I'environnement, 
qui traduit de fagon adequate Tensemble de ces parametres lors de 
remission des paquets aux bornes du modele logiciel du projet. 

Selon une autre particularite, la generation des predictions est 
effectuee par Temulateur du circuit sans avoir a prelever d'informations 
10 supplementaires sur le fonctionnement interne du circuit en projet. 

L'invention sera mieux comprise a I'aide de la description suivante 
d'un mode de realisation de l'invention et de mise en oeuvre du precede de 
l'invention, en reference au dessin annexe, sur lequel : 

- la figure 1 est un diagramme fonctionnel representant un emulateur de 
15 circuit integre ASIC represents avec la gestion d'une interface dans un 

emulateur d'environnement pouvant comporter une ou plusieurs interfaces,. 

- la figure 2 represente le meme emulateur, branche logiquement en parallele 
sur le modele logiciel de circuit ASIC a tester, ou emulateur du circuit en 
projet en modiB emetteur, represente avec la gestion d'une interface dans un 

20 emulateur d'environnement pouvant comporter une ou plusieurs interfaces, 

- la figure 3 est une variante de la figure 2 appliquee a un modele de circuit a 
deux noeuds, et 

- la figure 4 represente I'architecture interne d'un verificateur. 

Avant de decrire invention il est necessaire, pour sa bonne 
25 comprehension, de poser un certain nombre de definitions utilisees par la 
suite. 

Un emulateur est un programme ou un dispositif permettant de 
reproduire sur ses interfaces externes le meme fonctionnement que le(s) 
circuit(s) ou modeles de type HDL de circuit au(x)quel(s) il se substitue. 
30 Dans ce document, invention est appliquee au cas d'un circuit integre 

de type routeur avec antememoire car reconnu comme etant le cas le plus 
complexe. Dans la suite, le mot ROUTEUR designe : 



11 



3945/US 



- soit le modele de type HDL du circuit en projet, 

- soit remulateur du circuit en projet ("Design") en mode emission. 

La programmation objet a permis : d'une part, de structurer Temulateur 
de ROUTEUR en un ensemble de classes specialisees, d'autre part, de 
5 simplifier le traitement par la localisation et la specialisation de ces 
traitements a chaque instance de chaque classe, comme nous le verrons par 
la suite. 

Dans le contexte de la simulation logicielle ("Software"), la plate-forme 
de verification est constitute de Tensemble des modeles de generation de 
10 stimuli et des modeles d'observations aux interfaces du circuit en projet ou 
en conception ("Design") qui est a valider. Ces modeles d'observations 
constituent un emulateur de Tenvironnement du circuit en projet ("Design"). 

La methodologie de verification de la plate-forme de I'invention fait 
egalement usage d'un emulateur du projet ("Design") pouvant fonctionner 
15 suivant 2 modes : 

- Le mode controleur ("Checker") dans lequel Temulateur du 
circuit en projet ("Design") sert de reference pour la 
validation des reponses du circuit en projet ("Design") en 
fonction des stimuli d'entree appliques par I'emulateur 

20 d'environnement, ou des reponses de I'emulateur du circuit 

en projet en mode emetteur. 

- Le mode emetteur dans lequel I'emulateur du circuit en 
projet ("Design)" se substitue au projet ("Design") lui-meme 
dans des configurations de simulation autonomes pour la 

25 mise au point de la plate-forme de verification sans avoir a 

utiliser le modele de type HDL du projet ("Design"). 
L'ensemble des emulateurs (emulateur de circuit et emulateur 
d'environnement) constituant la plate-forme de verification sont des modeles 
objet ecrits en C^"^ connectes aux interfaces du modele en langage de type 
30 HDL de bas niveau du circuit en projet ("Design") via des adaptateurs 
d'interface en type HDL. Le degre d'utilisation du langage evolue par rapport 



12 



3945/US 



au degre d'utilisation du langage de bas niveau type HDL varie selon Tetat 
d'avancement de mise au point des ennulateurs. 

En general, on part d'une specification fonctionnelle de circuit 
contenant une majorite de langage C"" et juste des interfaces en langage de 
5 type HDL pour aboutir a un modele logiciel comportant une majorite de 
langage de type HDL de bas niveau et quelques interfaces en C"^"^. 
L'evolution du modele logiciel en langage de type HDL du circuit en cours de 
developpement se fait progressivement en utilisant des modeles 
intermediaires mis au point contenant une proportion plus equilibree de 

10 langage evolue par rapport a la proportion de langage de type HDL. 

Dans les adaptateurs d'interface, les echanges entre C** et de type 
HDL sont abstraits en evenements. Les evenements rendent aussi bien 
compte des echanges arbitraires de donnees contenues dans les paquets 
que des changements de valeurs sur les signaux de controle. Le paquet est 

15 la granularite de traitement atomique des modeles abstraits C^"*^ appartenant 
au niveau de description (dit protocole) des interfaces. 

En mode controleur ("Checker"), Temulateur du circuit en projet 
("Design") effectue ses controles en temps reel, c'est-a-dire que ses 
traitements s'executent en meme temps que la simulation qu'il peut 

20 interrompre des la detection d'une erreur au moment meme de son 
apparition. Cette caracteristique interessante du point de vue exploitation 
permet d'eviter de generer des fichiers de trace pendant {'exploitation 
normale et de generer les informations necessaires au diagnostique que 
lorsqu'il y a erreur, limitant ainsi la lourdeur des traitements posterieurs dits 

25 de post-processing. 

En mode controleur ("Checker"), Temulateur du circuit en projet 
("Design") peut construire ses controles sur la seule base des specifications 
fonctionnelles de niveau systeme sans prelevement d'informations 
supplementaires sur le fonctionnement interne du circuit en projet ("Design"). 

30 Cette propriete remarquable permet son application a 2 types de contextes 
differents : 
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- Le contexte de simulation C^VHDL du circuit en projet ("Design"), 
dans lequel I'emulateur du circuit en projet ("Design") est alors 
connecte a Tensemble des interfaces du modele logiciel en 
langage de type HDL de bas niveau du circuit en projet 
("Design"), sur lesquels il preleve les echanges de paquets des 
modeles d'observations via les adaptateurs d'interface ; 

- En execution C*^ seule, a partir de traces prelevees aux interfaces 
du modele logiciel du circuit en projet ("Design"), ces traces etant 
eventuellement reformatees sous forme de paquets avant d'etre 
rejouees en autonome par I'emulateur du circuit en projet 
("Design"). 

Les traces prelevees aux bornes du circuit en projet ("Design") a valider 
peuvent etre d'origines differentes : 

- Dans le contexte de la verification fonctionnelle, elles proviennent 
de la memorisation des paquets echanges au cours d'une 
simulation anterieure. Les traces peuvent se presenter, soit sous 
forme textuelle, soit sous forme de structures C"^* dites fibres 
stockees dans une base. 

- Dans le contexte de la mise au point materielle, elles proviennent 
du prelevement des stimuli aux bornes de rechantillon physique 
du circuit. Les stimuli abstraits en evenements sont reformates 
sous forme de paquets avant d'etre injectes a I'emulateur du projet 
("Design) " pour diagnostic en execution autonome. 

Les tests fonctionnels commandent le parametrage des paquets transmis au 
projet ("Design") cible via son environnement : 

- Dans le contexte de la verification fonctionnelle, les tests 
fonctionnels s'appuient sur I'interface programmatique applicative 
(API) de I'emulateur de Tenvironnement du circuit en projet 
("Design) a valider pour commander directement et precisement la 
succession des transactions a transmettre au projet pour 
execution. Chaque transaction est constitute au niveau de chaque 
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interface, d'un paquet requete et d'un ou plusieurs paquets 
reponses associes. Aussi bien les valeurs des parametres que les 
contraintes temporelles d'emission des paquets peuvent etre 
forcees a partir des tests. L'emulateur de renvironnement traduit 
de fagon adequate Tensemble de ces parametres lors de 
remission des paquets aux bornes du projet ("Design"). 

- Dans ce contexte, les tests fonctionnels ont egalement la 
possibilite de forcer, dans chaque composant du systeme, et en 
conformite avec le protocole de coherence assurant Tintegrite des 
donnees dans le systeme, les etats de depart des adresses des 
blocs accedes. Cette facilite permet de creer de fagon controlee 
des situations de coherence tres diversifiees et complexes sans 
avoir a reconstituer un historique d'execution permettant d'aboutir 
a ces situations. 

- Dans le contexte de la mise au point materielle, {'execution des 
tests fonctionnels se fait en situation reelle sur les processeurs du 
systeme, celui-cl incluant les echantillons physiques du circuit a 
valider. Les tests fonctionnels decrivent des programmes traduits 
en suite d'instructions a faire executer par les processeurs du 
systeme qui les traduiront eux-memes, si besoin est, en 
transactions adressees au systeme tout entier. 

- Dans ce contexte, les espaces d'adresses sont types. Aucun 
forgage direct sur le format des transactions ou I'etat des blocs 
accedes n'est possible. 

A cause de leur nature differente, il est impossible de reconduire en 
situation reelle sur les echantillons physiques, dans le contexte de mise au 
point, les tests fonctionnels prealablement elabores dans le contexte de la 
verification fonctionnelle et appliques via Temulateur de renvironnement sur 
le modele de type HDL du circuit en projet ("Design") pour la verification de 
sa conception avant sa realisation physique. 
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Sur la figure 1 , la reference 1 designe un emulateur de circuit integre 
utilisable notamment pour les circuits integres en projet qui doivent etre 
realises a la demande, et appeles ASIC. L'invention s'applique a tous types 
de circuits integres, par exennple un circuit simple de type microcalculateur 
5 ou un systeme connplexe, tel que notamment un systeme multi-noeuds a 
memoire coherente. Les noeuds (Noeud 1,..., Noeud n) de memoire sont 
interconnectes par le circuit integre en projet. Un systeme multi-noeuds peut 
etre, par exemple, un ensemble de cartes de circuits integres comportant des 
multiprocesseurs et/ou des entrees-sorties avec antememoire fonmant une 

10 pluralite de noeuds de communication contenant des memoires, et dont les 
noeuds peuvent emettre des requetes simultanees vers des adresses de 
memoire partagee. Le circuit integre physique ASIC est absent de la figure 1 
et un modele logiciel de ce circuit en projet en langage type HDL de bas 
niveau porte la reference 40 sur la figure 2. L'emulateur 1 communique avec 

15 un ou plusieurs noeuds (Noeud 1,..., Noeud n). Chaque noeud peut 
communiquer avec une station client 50 ou I'ensemble des noeuds 
communique avec une seule et meme station client 50. L'emulateur 1 est 
constitue autour d'un systeme de traitement de donnees 10, tel qu'un 
calculateur, qui regoit, en memoire 2, des donnees 20 de specification 

20 fonctionnelle en langage de haut niveau, par exemple C^"^, du modele 40 de 
TASIC du projet a realiser en langage de type HDL. Les donnees 20 
definissent les reponses que doit presenter, sur ses sorties, I'ASIC, en projet 
a des etats successifs presentes a ses entrees. Un bus d'acces local ou un 
moyen de communication 1B d'acces direct a l'emulateur 1 , est ici prevu pour 

25 le gerer. 

D'une fagon generate, comme evoque plus haut, les donnees de 
specification fonctionnelle 20 determinent que I'ASIC en projet a definir par 
son modele de type HDL, presente, a un instant donne, un etat de sortie 
determine, fonction de I'etat d'entree instantane qui lui est impose, et fonction 
30 des etats de ses memoires "internes" eventuelles (EMI), usuellement 
existantes dans les ASICs. Par memoire interne, on designe les memoires 
dont le contenu, lisible ou non de I'exterieur de I'ASIC 40, agit sur I'etat 
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d'autres circuits logiques ou sequentiels de TASIC 40. Les etats des 
memoires dependent, de fa9on generate, des etats anterieurs d'entree de 
TASIC, c'est-a-dire de I'historique des sequences de stimuli d'entree et sont 
memorises dans une memoire 962 et dans le coeur 961 de I'emulateur. 
5 L'emulateur 1 comporte egalement, en memoire 9, un logiciel 90 

d'exploitation des donnees 20 de specification fonctionnelle. Le logiciel 90 
comporte des programmes d'elaboration et de validation progressive de 
sequences de test de validation fonctionnelle de TASIC en projet. A^chaque 
pas d'une sequence de test de validation fonctionnelle, le vecteur ou etat de 

10 sortie, determine en fonction d'un vecteur d'entree actuel et de Thistorique, 
est memorise et mis a jour en memoire 91. Cette memorisation peut porter 
sur Tetat des memoires internes (EMI) de I'ASIC en projet, ce qui en pratique 
est necessaire a chaque pas pour calculer les vecteurs de sortie instantanes 
successifs, et surtout elle peut porter sur revolution des etats des memoires 

15 internes de i'ASIC en fonction des vecteurs d'entree successifs, representant 
les effets de Thistorique. 

II y a done une double "modulation" par rapport a une simple bijectlon 
entree/sortie. 

En effet, d'une part, des vecteurs d'entree differents, appliques a des 
20 instants distincts dans une sequence de stimuli, peuvent avoir des effets qui 
"convergent", c'est-a-dire correspondent a un meme vecteur de sortie, par 
I'effet des etats des memoires internes. 

D'autre part, des vecteurs d'entree identiques, appliques a des 
instants distincts dans une sequence de stimuli, peuvent avoir des effets qui 
25 "divergent" en produisant des vecteurs de sortie differents, par I'effet des 
6tats des memoires internes. 

La specification fonctionnelle definie par les donnees 20 peut specifier, 
une table de verite, ou de comportement, correspondant aux fonctions des 
diverses parties ou divers elements de circuit fonctionnels du modele de type 
30 HDL 40 de I'ASIC, mais aussi des plages de retard de propagation a 
respecter entre chaque entree et chaque sortie. La plate-forme de verification 
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verifie ainsi que les reponses de TASIC sont situees dans des plages de 
temps de reponse specifiees dans la specification fonctionnelle 20. 

Le logiciel 90 d'elaboration des sequences de test de validation 
fonctionnelle, interprete ainsi les donnees de specification 20 pour fournir, en 
5 tenant compte des etats des memoires internes (EMI) de I'emulateur que 
sont le coeur 961 et les memoires 962 de statut dans la memoire cache 
(antememoire), le vecteur de sortie associe au vecteur d'entree. Le vecteur 
d'entree est fourni par un operateur utilisateur mettant au point le programme 
de test (70). 

10 La reference 30 designe un bus informatique ou un moyen de 

communication, relie soit directement a un terminal d'un utilisateur soit a un 
reseau de transmission de donnees, permettant a un utilisateur de dialoguer 
en mode client-serveur avec I'emulateur 1 a travers un circuit 21 generateur 
de stimuli, traduisant les commandes transmises, par exemple par une 

15 interface de communication ("socket"), en stimuli et un circuit 22 gestionnaire 
d'interface, gerant Tinterfagage entre la station 50 d'au moins un client, et 
I'emulateur (1). Get emulateur a ici une fonction d'interface de dialogue 
utilisateur-emulateur (50,1), utilisee dans une premiere etape illustree par la 
figure 1. Comme cela est explique plus loin en regard de la figure 2, le circuit 

20 21 sert a transmettre les stimuli generes par le client utilisateur dans la phase 
de validation fonctionnelle pour les appliquer en entree du modele 40 en 
langage de type HDL de I'ASIC et a I'emulateur 1, et le circuit 22 est un 
moniteur gerant les interfaces en entree et en sortie entre une station client 
(50) et, d'une part, I'emulateur 1 et, d'autre part, les circuits 1 1 convertisseurs 

25 de langage evolue vers le langage de type HDL du modele logiciel 40 de 
I'ASIC. Ces deux circuits (21, 22) constituent, avec I'adaptateur 11, 
I'emulateur d'environnement. Une memoire 210 du circuit generateur de test 
21 est prevue pour stocker des sequences de stimuli d'entree, la mise au 
point et la memorisation des sequences d'entree dans leur forme definitive 

30 etant, dans cet exemple, effectuee par le programme. 

Le schema de la figure 1 illustre ainsi un mode de fonctionnement dit 
« emission », dans lequel I'emulateur 1, recevant, par le bus 30, des 
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commandes de Tutilisateur specifiant des sequences de stimuli d'entree, 
emet en retour des stimuli de reponse representant la reponse prevue pour 
le modele logiciel en langage de type HDL 40 de TASIC, permettant ainsi de 
mettre au point Temuiateur d'environnement 51 . 
5 Le programme global de sequences de test 51, stocke cote client 

passera transitoirement dans la memoire 210 d'un circuit 21 generateur de 
stimuli. 

Dans cet exemple, comme Tillustre la figure 1 , I'emulateur 1 est relie 
par le noeud 122 aux circuits 21, 22 a travers deux circuits 11 et 12 

10 d'adaptation entre les deux langages de programmation, ces circuits 
d'adaptation etant relies en serie et ayant des fonctions d'adaptation 
mutuellement inverses. Le circuit d'adaptation 11, relie directement aux 
circuits 21 et 22, transforme des (commandes de) stimuli provenant de ceux- 
ci, ecrits en langage de haut niveau, ici le langage C"^"*^, en un langage de bas 

15 niveau, ici le langage de type HDL, directement interpretable par le modele 
logiciel 40 en langage de type HDL de I'ASIC prevu, c'est-a-dire ici des 
commandes prevues pour etre appliquees, comprises et executees par celui- 
ci. Les stimuli fournis par le circuit 21 en langage C'^'*' sont transformes en 
langage de type HDL par un port d'entree/sortie 1 1 1 du circuit d'adaptation 

20 C'^^'^^/HDL 11. II peut s'agir de commandes binaires tres elementaires, par 
exemple de portes logiques, ou de commandes plus elaborees, par exemple 
pour commander un processeur du modele de type HDL 40 de TASIC. Ces 
dernieres commandes peuvent, en particulier necessiter une macro- 
commande, c'est-a-dire une sequence de stimuli de commandes 

25 elementaires. 

Le circuit 12 d'adaptation inverse HDL/C^, relie au port 111, sert de 
frontal pour I'emulateur 1, afin que celui-ci, qui utilise le langage C^^, exploite, 
apres adaptation du langage de type HDL vers le langage C"*^"^, les stimuli 
initialement traduits en langage de type HDL par le circuit 11. Ce circuit 11 

30 permet d'exprimer les stimuli dans leur forme reelle d'exploitation, prevus 
pour etre effectivement appliques au modele logiciel 40 en langage de type 
HDL de I'ASIC de la figure 2, a partir du port 111. Cela permet done de tester 
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egalement le bon fonctionnement du circuit 11 d'adaptation CVHDL pour 
chacun des stimuli d'entree. 

Le circuit 11 d'adaptation C'^/HDL fournit ainsi, par le port 
d'entree/sortie 111, des commandes ou programmes de niveau physique et 
5 logique directement compatibles avec le modele logiciel 40 en langage de 
type HDL de I'ASIC prevu. Ces commandes sont la traduction de 
commandes logicielles ou programmes en langage de plus haut niveau, plus 
abstraites, symboliques. constituant un descripteur specifiant les commandes 
physiques et logiques a appliquer reellement. Ainsi, dans cet exemple, 

10 I'elaboration des sequences de stimuli symboliques du programme de test 
51 , en langage de niveau superieur au niveau physique et logique du modele 
40 de TASIC, permet de s'affranchir des particularites physiques et/ou de 
langage de programmation interne au modele logiciel de type HDL 40 de 
TASIC et facilite done I'ecriture de ces sequences. Comme indique, c'est le 

15 circuit 11 d'adaptation C^VHDL qui, dans une etape suivante de celle 
d'ecriture des sequences, effectue la transposition voulue pour I'executlon 
pratique des sequences du programme de test 51 . 

Dans le sens oppose, de I'emulateur 1 vers le bus 30, les circuits 
d'adaptation de langage 12 et 11 ont les fonctions inverses de celles 

20 respectivement decrites, le circuit 12 transformant les donnees regues de 
I'emulateur 1 et formulees en langage de haut niveau, C'*^, en des donnees 
en langage de bas niveau, de type HDL. Le circuit 11 retransforme les 
memos donnees qui ont ete formulees en langage de bas niveau, c'est-a-dire 
de type HDL, par le circuit 12 en des donnees en langage de haut niveau, 

25 c'est-a-dire C^"". 

Comme indique ci-dessus, le modele logiciel de type HDL 40 de 
I'ASIC, absent de la figure 1, y est represente fonctionnellement par 
Tensemble reference 140 qui est constitue par I'emulateur 1 avec ici, en 
frontal, le circuit d'adaptation 12, dont un port d'entree/sortie 121 regoit les 

30 commandes de bas niveau du port 111 et les transmet a I'emulateur 1, par 
un port d'entree/sortie 122, apres les avoir retransformees en un langage de 
haut niveau. En pratique, ici, c'est le meme que celui utilise par le circuit 
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generateur de stimuli 21, c'est-a-dire le langage C"", mais I'invention 
s'applique egalement au cas ou le langage utilise par le circuit 21 serait, 
cartes evolue, mais different de C^"^, Ainsi. I'utiiisateur peut dialoguer avec 
Temuiateur 1 au moyen d'un langage de haut niveau, C^, les circuits 
5 d'adaptation de langage 11 et 12 ayant des effets qui s'annulent et qui sont 
ainsi totalement masques fonctlonnellement a Tutilisateun dans la mesure ou 
le circuit 1 1 ne presente pas de defaut de fonctionnement, comme evoque 
precedemment. 

Comme indique plus haut, I'ensemble constitue par I'emulateur 1 et 
10 son adaptateur de langage 12 constitue un emulateur parfaitement conforme 
au models logiciel 40 en langage de type HDL de I'ASIC, mais la mise au 
point de ces sequences de stimuli s'effectue par utilisation du langage de 
haut niveau, s'affranchissant des specificites materielles de I'ASIC et des 
specificites des langages de bas niveau de description des circuits integres, 
15 tel que le langage de type HDL. Cette mise au point permet aussi de verifier, 
en particulier, que le circuit d'adaptation 11, qui sera utilise dans la 
configuration de la figure 2, fournit I'adaptation voulue pour chaque type de 
stimuli du programme de test 70 mis au point. En d'autres termes, la mise au 
point du programme de test 70 s'effectue dans le langage de haut niveau 
20 C*** mais elle comporte une verification du bon fonctionnement de' 
r « echelle » (circuit d'adaptation 12) qui permettra de faire « descendre » le 
programme de test 70 du langage symbolique C^"^ au langage de bas niveau 
de type HDL directement exploitable par le modele de type HDL 40 de 
I'ASIC. 

25 Les sequences de test de validation fonctionnelle sont mises au point 

par un utilisateur relie au bus 30 en envoyant les stimuli d'entree et recevant 
en retour des reactions du logiciel 90 d'exploitation en memoire 9, qui signale 
des defauts eventuels dans Telaboration du programme global de sequences 
de test, et permet leur correction. Une fois les sequences de test de 

30 validation fonctionnelle mises au point, Tensemble de ces dernieres 
constituant le programme de test 51, est recopie dans la memoire 
d'exploitation 210 du circuit generateur de stimuli 21 . 
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La figure 2 illustre une phase suivante de fonctionnement, dite de 
« verification », dans laquelle est effectue un test de validation fonctionnelle 
du modele logiciel 40 de I'ASIC en langage de type HDL. Dans cette pliase, 
sous la commande des stimuli du programme de test 51 emis par la memoire 
5 210, les divers etats -d'entrees soumis au modele logiciel de TASIC, sont 
egalement soumis, en entree, a Temulateur 1 qui elabore, par le programme 
90 en dynamique, les sorties previsibles qui apparaissent successivement en 
sortie 230 de Temulateur 1 , en reutilisant precisement la meme specification 
fonctionnelle 20 que celle utilisee pour le mode « emission ». Les sorties de 
10 Temulateur 1 evoluent en synchronisme avec I'etat, reel, des sorties du 
modele logiciel 40 de TASIC en langage de type HDL, ce qui permet de 
detecter toute discordance du fonctionnement cible prevu, defini par 
I'emulateurl. 

Sur la figure 2, I'emulateur 1 dialogue directement avec un circuit 

15 generateur de stimuli 21 et un circuit moniteur d'interface 22 pour chaque 
noeud du modele logiciel, puisque I'adaptatlon de langage C^VHDL effectuee 
par le circuit d'adaptation 11a ete verifiee selon le schema de la figure 1 . Le 
circuit d'adaptation inverse 12 est done omis- Le modele logiciel 40 de TASIC 
en langage de type HDL est alors relie au port 1 1 1 du circuit d'adaptation 1 1 

20 (dessine retourne), servant de frontal d'adaptation de langage. En d'autres 
termes, le modele logiciel 40 de TASIC en type HDL de la figure 2 remplace 
I'ensemble 140 constitue, sur la figure 1, par I'emulateur 1 avec son circuit 
frontal d'adaptation 12. L'emulateur 1 de la figure 2 sert alors a controler, par 
comparaison, les reponses reelles du modele logiciel 40 de I'ASIC en 

25 langage de type HDL a celles prevues par I'emulateur 1 . 

Le port 112 est ici represents eclate en un port d'entree 1 12A, relie au 
circuit generateur de stimuli de test 21 par une liaison 25, et un port de sortie 
112B relie a un comparateur 23. Le modele de type HDL de I'ASIC 40 
presente ainsi, pour son environnement, une interface 112A, 112B de 

30 dialogue dans le langage de haut niveau, ici C"*^"^, utilise par les autres circuits 
1,21,22et23, 
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L'emulateur 1 est alors relie en entree a la liaison 25, done 
directement en parallele sur le port d'entree 112A pour recevoir, tout comme 
le modele de type HDL 40 de TASIC a travers le circuit d'adaptation 11, les 
sequences de stimuli memorisees en memoire 210 correspondant au 
5 programnne de test de validation 70 en langage de haut niveau, qui a ete mis 
au point selon le schema de la figure 1. L'emulateur 1 fournit en reponse, au 
comparateur 23, un etat, ou stimuli, ou encore vecteur, de sortie, fonction 
des donnees de specification 20, qui est considere comme etant Tetat de 
sortie cible, ou de reference, associe a I'etat d'entree. II s'agit done, parmi les 

10 etats de sortie previsibles, de celui qui est determine ou selectionne d'apres 
I'etat d'entree fourni au verificateur 960. Nous expliciterons ulterieurement le 
role du verificateur 960. 

Le modele le modele logiciel en langage HDL de I'ASIC fournit aussi, 
de son cote, un etat de sortie qui est transforme par le circuit d'adaptation 1 1 

15 pour etre presente dans le langage de haut niveau C^"*", cet etat de sortie 
etant en principe identique a celui prevu par l'emulateur 1. Le circuit 
comparateur 23 a ete dessine pour illustrer la comparaison des sorties qu'il 
regoit et il fait en realite fonctionnellement partie de l'emulateur 1, Le 
comparatetir 23 compare les etats de sortie du modele de type HDL 40 de 

20 rASIC, regus par le port 112B, et les stimuli de sortie foumis par le 
verificateur 60 de Temulateur 1 pour detecter une eventuelle discordance et 
la signaler a I'utilisateur client. En pareil cas, cela indique un defaut de 
conformite du modele logiciel 40 en langage de type HDL de I'ASIC avec la 
specification 20, du a un defaut de conception ou a une erreur de 

25 fonctionnalite au niveau de Tensemble modele ASIC-programme de test. La 
sortie du comparateur 23 remplit un fichier enregistrant des notifications 
d'erreurs en cas de comparaison non concluante. Le circuit moniteur 
d'interface 22 et le circuit generateur de stimuli 21 regoivent les sorties du 
modele de type HDL pour permettre de tenir compte des reponses 

30 anterieures dans la generation de stimuli et pour le generateur 21 generer 
des fichiers de trace. 
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Comme evoque plus haut, le client peut, en variante ou en 
complement, ecrire et foumir tout ou partie de la specification fonctionnelle 
20 sous la forme d'un programme dans un langage de bas niveau, tel que 
defini plus haut, remplafant ou completant un programme homologue de 
5 haut niveau. Dans le cas ou la specification fonctionnelle 20 est ainsi definie 
au total dans deux langages differents par leurs niveaux ou autre, le client 
utilisateur commando alors Temulateur 1 pour que le logiciel 90 d'elaboration 
de test, prevu a cet effet, effectue une co-simulation, ou co-emulation, par 
synchronisation d'execution des deux programmes de specification. 

10 La figure 3 reprend les elements representes sur la figure 2, avec, 

toutefois, une duplication du circuit d'adaptation du langage 1 1 1 
respectivement II2 pour un premier et un second noeud et des circuits 21 1, 
21 2, 22i, 222 et du bus 30 d'interface de liaison avec les clients utilisateurs, 
pour un fonctionnement multi-noeud (Noeud 1, Noeud 2) et multi-utilisateur 

15 (Client 1, Client 2). 

La figure 3 represente un mode de realisation de la plate-forme de 
verification de invention dans laquelle on inclut le modele d'elaboration de 
prediction, ou emulateur 1 , constituant le verificateur permettant de verifier la 
conformite du modele de type HDL de I'ASIC developpe par rapport a la 

20 specification fonctionnelle et aux tests elabores pour verifier cette 
specification fonctionnelle. 

Dans la suite du document, ROUTEUR designe : soit le modele 
logiciel en langage de type HDL du circuit en projet, qui est un circuit routeur 
permettant le routage d'information dans un systeme multi-noeuds, soit 

25 Temulateur de ce circuit en mode emission. 

Une transaction du systeme s'execute de la fagon suivante. 
Le contexte d'execution de Temulateur du ROUTEUR est un systeme 
multi-noeuds a memoire coherente, ces noeuds etant interconnectes par le 
ROUTEUR. Un systeme multi-noeuds peut etre, par exemple un ensemble 

30 de cartes de circuits integres comportant des multiprocesseurs, et/ou des 
entrees-sorties formant une pluralite de noeuds de communication contenant 
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des memoires et dont les noeuds peuvent emettre des requetes simultanees 
vers des adresses de memoire partagee. 

Les composantes d'une transaction sont les suivantes. 

Un noeud peut emettre des requetes dites primaires, de type lecture, 
5 ecriture, invalidation. Ces requetes recevront une ou plusieurs reponses dites 
primaires. Le ROUTEUR peut etre amene, pour traiter une requete primaire 
emise par un premier noeud P, a generer une ou plusieurs requetes dites 
secondaires vers des noeuds S distincts du premier noeud P. Chaque noeud 
S emettra une ou plusieurs reponses dites secondaires. L'ensemble de ces 
10 reponses secondaires servira au ROUTEUR a emettre la reponse primaire. 

L'ensemble {requete et reponse(s) prlmaire(s), requete(s) et 
reponse(s) secondaire(s)} constituent une transaction. 

Les noeuds disposent d'une antememoire pour memoriser les blocs de 
memoire utilises contenant, soit des adresses, soit des donnees. 
15 Le ROUTEUR dispose d'une antememoire (appelee DIRECTORY 

dans la suite du document) pour memoriser les blocs utilises par les noeuds 
d'apres leur adresse. Pour une adresse utilisee par un ou plusieurs noeuds, 
un vecteur de presence est gere avec, par noeud, un temoin de presence. 
Cette memoire cache permet de limiter la generation des requetes 
20 secondaires aux noeuds utiles pour Texecution de la transaction (exemple : 
invalidation propagee vers les noeuds qui ont le temoin de presence valide) 

Le ROUTEUR peut etre amene a traiter plusieurs transactions 
relatives au meme bloc memoire. Get ensemble de transactions est appele 
collision. Le ROUTEUR les prend en compte de maniere serielle. L'ordre 
25 dans lequel le ROUTEUR les prend en compte est appele ordre de 
serialisation. 

Pour chaque requete primaire, le ROUTEUR est amene ^ detemiiner 
Tetat final du bloc memoire. 

[cas a] Si la determination de cet etat final par le ROUTEUR requiert 
30 une ou plusieurs {requete, reponses(s) secondaire(s)}, la transaction passe 
en section critique (jusqu'a la reception des reponses secondaires); visible 
de Temulateur. 
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[cas b] Dans le cas contraire, Temulateur n'a connaissance de la 
decision du ROUTEUR qu'au travers des reponses primaires. 

La difficulte pour remulateur de suivre Tactivite du ROUTEUR vient du 
fait que les transactions repondant au second cas [cas b] ont leur point de 
5 serialisation non visible par I'emulateur. 

Par centre, les transactions repondant au premier cas [cas a] ont leur 
point de serialisation visible de Temulateur, et offrent a Temulateur une aide 
importante dans le suivi de I'activite du ROUTEUR. 

L'emulateur en mode verification va effectuer des predictions. 
10 Pour suivre I'activite du ROUTEUR en cas de collision, Temulateur doit 

predire Tensemble des ordres de serialisation possibles et pertinents 
qu'amenent cette collision. 

La generation des predictions consiste en la production, pour chaque 
cas de serialisation envisage, des profils des requetes secondaires, 
15 reponses primaires et secondaires qui devraient apparaitre aux interfaces du 
ROUTEUR. 

L'observation d'une sortie du ROUTEUR (requete secondaire, 
reponse primaire) est confrontee aux profils des predictions. 
En cas de non-correspondance, la prediction est rejetee. 
20 Si aucune prediction ne repond a I'observation, Temulateur signale 

une erreur. 

La programmation objet a permis : d'une part, de structurer l'emulateur 
de ROUTEUR en un ensemble de classes specialisees et, d'autre jDart, de 
simplifier le traitement par la localisation et specialisation de ces traitements 
25 a chaque instance de chaque classe. 

Les classes suivantes sont utilisees par I'invention : 

• La classe "TxnId". 

Une instance (T) de cette classe assure le suivi de I'execution d'une 
transaction. 

30 Cette instance T gere une collection d'hypotheses d'execution (qui 

sont des instances de la classe TxnIdHypothesis). 
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Une hypothese d'execution est conservee tant que les observations 
des sorties du ROUTEUR sont conformes aux predictions faites par cette 
hypothese. 

L'execution de cette instance T est consideree comme correcte tant 
5 qu'il existe au moins une hypothese vivante. 

Cette instance T est en charge de verifier la fin d'execution de la 
transaction (c'est-a-dire qu'il existe des hypotheses vivantes ayant observe 
toutes les sorties du ROUTEUR predites). 

• La classe "TxnIdHypothesis". 

10 Une instance (TH) de cette classe assure le suivi d'une hypothese 

d'execution d'une transaction. 

Cette instance (TH) gere une instance de la classe Syst_Xaction. 
Cette instance (TH) est en charge de controler que les observations 
des sorties du ROUTEUR sont conformes aux predictions de cette 
15 hypothese. 

L'instance (TH) est en charge de gerer les reponses aux requetes 
secondaires. 

• La classe "Syst_Xact ion". 

Une instance (SX) de cette classe memorise les informations relatives 
20 a la requete primaire, et a la (aux) requete(s) secondaire(s) predite(s) par 
rhypothese attachee. 

Cette instance (SX) memorise egalement des marques d'execution de la 
transaction. 

• La classe "CollisionScenario". 

25 Une instance (CS) de cette classe gere une serialisation possible de 

transactions en collision. Cette instance (CS) gere egalement le cas de non- 
collision (c'est-a-dire le cas d'une transaction en cours sur un autre bloc 
memoire). 

Pour chaque transaction concernee, une hypothese d'execution de 
30 cette transaction est attachee a l'instance (CS). 
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L'instance (CS) gere une liste ordonnancee d'instances de la classe 
"CollisionElement". 

Get ordonnancement reflete la serialisation des transactions en 
collision. 

• La classe "CollisionElement". 

Une instance (CE) de cette classe gere I'etat d'execution d'une 
hypothese d'execution d'une transaction dans un contexte de collision. 
Les principaux etats d'execution sont : 

- ASLEEP : aucune observation de sorties du ROUTEUR n'a ete faite 
pour cette hypothese. 

-PREDICTED : toutes les predictions pour assurer le suivi de 

rhypothese sont elaborees. 
-WTSNOOP, WTCMP : la transaction est en section critique, en 

attente d'une (de) reponse(s) secondaire(s). 
-WTTRANS : aucune observation de sorties du ROUTEUR ne peut 

avoir lieu pour cette hypothese. 
-COMPLETED : la transaction est terminee. 

Pour les etats ASLEEP et WTTRANS, aucune prediction n'a ete 
realisee. 

Uetat WTTRANS est atteint pour une hypothese dont la serialisation 
devra attend re la fin de section critique d'une autre transaction. 

L'instance (CE) gere egalement une instance de la classe 
"Directory Entry". 

• La classe "DirectoryEntry". 

Une instance (DE) de cette classe gere I'etat (ESI) d'un bloc memoire, 
ainsi que le vecteur de presence de ce bloc dans les noeuds peripheriques 
du ROUTEUR. 

Ces informations refletent celles dont le ROUTEUR dispose pour 
gerer le bloc. 

Chaque indice du vecteur de presence (ou temoin de presence) 
indique : 

- soit la presence certaine du bloc dans le nceud attache ; 
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- soit la presence potentielle du bloc dans le noeud attache. 

Dans certaines occasions (par exemple Texecution de certains types 
de transaction dans un contexte de collision), le ROUTEUR peut effacer ou 
maintenir un temoin de presence, sans indication de cet evenement au 
5 travers de sorties specialisees observables par Temulateur. 

• La classe "Transition". 

Cette classe gere I'activation d'une transition relative a un evenement 
(EV) (requete primaire, ou reponse secondaire dans un contexte de section 
critique) et a une instance DE. 
10 La transition a activer est recherchee dans une table (instance de la 

classe TransitionTable), 

Cette activation conduit a la mise a jour de instance (DE) et a 
Tactivation d'une instance de la classe "TransitionAction". 
La classe "TransitionTable". 
15 Cette classe decrit de fagon generique toutes les transitions 

autorisees par le protocole. 

Pour chaque etat d'une instance (DE), pour chaque type d'eyenement 
EV, sont specifies comment mettre a jour {'instance DE et {'instance de la 
classe "TransitionAction" a activer. 
20 ' •La classe "TransitionAction". 

Cette classe englobe les differents types d'action generiques a 
accomplir suite a la reception d'un evenement EV. 

Ces actions prennent en parametres la requete primaire, le contenu 
de I'instance DE associee. 
25 Parmi ces actions, on trouve entre autres : 

- la propagation d'in validation vers les noeuds ayant le temoin de 
presence dans {'instance DE; 

- la propagation vers le noeud detenteur du bloc memoire cible, d'une 
lecture ou mise a jour de ce bloc; 

30 - la propagation d'une reponse vers le noeud initiateur de la requete 

primaire. 
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Le terme « propagation » reflete la generation des predictions qui 
seront confrontees aux observations des sorties du ROUTEUR. 

• La classe "Directory". 

Une instance (D) de cette classe gere les instances DE associees aux 
5 blocs memoires presents dans les filtres du ROUTEUR. 

Une instance DE indique un etat stable du bloc si aucune transaction 
n'est en cours d'execution sur ce bloc. 

Dans le cas contraire, I'entree DE memorise les instances T en cours 
d'activite sur ce bloc. 
10 Le prochain etat de cette instance DE est alors en cours d'evaluation 

dans les differentes instances CE/CS associees a ces instances T. 

• La classe "VerifierCore". 

Une instance (VC) de cette classe gere I'ensemble de Tactivite. 
VC regoit les stimuli (requetes/reponses primaires/secondaires), cree 
15 les instances T a la reception des requetes primaires, soumet les stimulis a 
ces instances et les detruit en fin de transaction. 

Les algorithmes du ROUTEUR realisent les fonctions suivantes: 

• Fonction de generation des predictions : 

Sur observation d'une requete secondaire ou reponse primaire (emise 
20 par le routeur) relative a une transaction t, tous les scenario pertinents (i.e. 
differents ordres de serialisation) mettant en jeu cette transaction et celles en 
collision sont evalues. 

• Fonction d'elimination de predictions : 

Une prediction est ecartee (i.e. I'instance CS de la classe 
25 GollisionScenario est detruit) si, dans cette instance CS, Tetat de I'instance 
cible de la classe "CollisionElement" n'est pas compatible avec Tobservation, 
ou si, dans cette instance CS, la prediction geree par {'instance cible de la 
classe "TxnIdHypothesis" n'est pas conforme a I'observation (exemple : non- 
conformite entre profil de Tobservation et de la prediction). 
30 • Fonction de re-ajustement de mauvaise prediction : 
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Dans certaines occasions (execution de certains types de transaction 
dans un contexte de collision), le ROUTEUR peut effacer ou maintenir un 
temoin de presence dans son antememoire (Directory), sans indication de 
cet evenement au travers de sorties specialisees observables par 
5 remulateur. Par defaut, Temulateur de ROUTEUR genere des predictions 
avec temoin de presence efface. 

Si une observation montre que le choix inverse serait plus judicieux, 
les instances de la classe "CollisionScenarios" concernees sont re-evaluees 
en maintenant le bit de presence en question. 
10 • Fonction de reduction du nombre d'hypotheses valides : 

Pour assurer le suivi d'une collision, Temulateur de ROUTEUR est 
amene a gerer un nombre d'instances de la classe "CollisionScenario" qui 
peut devenir eleve. 

Certains cas de collision peuvent produire les memos observations 
15 pour les serialisations obtenues en permutant I'ordre de prise en compte des 
transactions concernees. 

Pour limiter le nombre d'instances de la classe "CollisionScenario", 
remulateur de ROUTEUR detecte dans chaque instance "CollisionScenario", 
les sous-ensembles d'instances de "CollisionElement" dans Tetat 
20 COMPLETED ou PREDICTED, pour lesquels I'etat de I'instance DE attachee 
n'a pas evolue. 

Ces sous-ensembles sont re-ordonnances. Les doublons sont 
elimines 

• Fonction de terminaison des collisions : 
25 L'emulateur de ROUTEUR detecte, sur I'ensemble des instances de la 

classe "CollisionScenarios" relatifs a une collision, les situations ou les n 
premieres instances de la classe "CollisionElements" sont relatifs aux 
memos transactions et aboutissent a des etats de Tantememoire (Directory) 
compatibles. 

30 Ces instances de la classe "CollisionElements" sont alors detruites, 

I'instance de la classe '"DirectoryEntry" correspondante dans la Directory est 
mise a jour. 
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L'organisation de remulateur ainsi defini a permis de simplifier le 
traitement par la localisation et la specialisation de ces traitements a chaque 
instance de chaque classe, d'isoler une transaction, une collision, et de 
specialiser les classes pour permettre une genericite des traitements. 
5 L'isolation d'une transaction, d'une collision est obtenue par le fait 

qu'une transaction est modelisee au travers d'une entree dans la table des 
transactions. Cette entree consiste en un pointeur vers une instance T de la 
classe Txnid. Cette instance pointe vers des instances TH de la classe 
"TxnIdHypothesis". Chaque instance TH pointe vers une instance SX de la 
10 classe "Syst_Xaction", vers une instance CS de la classe 
"CollisionScenario", et dans cette instance de la classe "CollisionScenario", 
vers une instance CE de la classe "CollisionElement". 

Cette instance CE pointe vers une instance DE de la classe 
"DirectoryEntry". 

15 Les avantages de cette organisation sont, d'une part, Tetancheite 

entre les traitements des transactions et, d'autre part, le suivi aise d'une 
transaction, d'une collision (objets lies par pointage). 

L'etancheite entre les traitements des transactions assure une 
robustesse des traitements par rapport a la charge, une facilite de mise au 
20 point (un probleme lie au traitement d'une collision est ind^pendant de la 
charge et peut done etre analyse en rejouant uniquement cette collision). 

Le suivi aise des traitements allege les phases de mise au point et le 
suivi du programme. 

La specialisation des classes et la genericite des traitements sont 
25 dues au fait que les classes "Transition", "TransitionTable" et 
"TransitionAction" sont specialisees dans le traitement des transitions et 
gerent de maniere independante une part tres importante du protocole. Elles 
peuvent etre facilement adaptees a d'autres protocoles de type MESI. 

Les classes "CollisionScenario", "CollisionElement" sont specialisees 
30 dans le traitement des ordres de serialisations. Les seules infoVmations 
manipulees sont les etats possibles des transactions (etat final du bloc 
predictible, section critique necessaire) et les etats de Tantememoire 
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(Directory) produits par les transitions. Des algorithmes de limitation du 
nombre de "CollisionScenario", independants du protocole, peuvent etre 
appliques, bases sur les etats finaux fournis par les transitions. 

Les classes "Txnid", "TxnIdHypothesis", "Syst_Xaction" sont 
5 specialisees dans le suivi de I'execution d'une transaction (memorisation des 
requetes secondaires en cours, divers temoins d'execution, prise en compte 
des reponses secondaires) et dans la comparaison des profils des 
predictions et observations. 

Les classes"Directory" et "DirectoryEntry" sont specialisees dans la 
10 gestion de la memoire cache (antememoire). 

Tous les protocoles de memoire cache peuvent etre faciiement 
integres. 

La figure 4 represente Tarchitecture interne du verificateur. 

Chacun des clients emet, a travers des commandes d'appels JCALL, 

15 des requetes de tests du modele de type HDL 40 du circuit ASIC. Ces 
commandes sont transmises au generateur de stimuli 21 et moniteur 
d'interface 22 qui les envoie, d'une part, vers le circuit verificateur de 
Temulateur 1 pour elaborer des predictions de reponses du modele de 
I'ASIC, d'autre part, vers le circuit 11 convertisseur d'un langage evolue en 

20 C*^ vers un langage de bas niveau de type HDL de description du hardware 
du circuit ASIC et, a travers ces convertisseurs, vers le modele de type HDL 
du circuit ASIC. 

Les requetes sont regues par les Interfaces de traitement XSEqGen 
(figure 4) du verificateur 960 et egalement utilisees dans les circuits 21, 22 

25 generateurs de stimuli pour transmettre et verifier les paquets de requete. 
Deux instances sont utilisees pour chaque interface du verificateur 60, une 
premiere recevant les requetes a destination de I'emuiateur 1 agit comme 
repondeur, Tautre transmettant les requetes de I'emuiateur agit comme un 
emetteur mais toutes deux sont identiques. 

30 Le noyau verificateur 961 est le composant central elaborant les 

predictions en fonction des adresses, dans le repertoire 962 (SF/ED) de la 
memoire, du vecteur de presence des stimuli de reponse et des paquets 
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regus representant les stimuli d'entree. L'organisation du noyau 961 de 
verification est reallsee autour de classes instanciees sous fornne d'objets. Le 
noyau verificateur 961 memorise des registres de configuration pour le 
routage des requetes non coherentes, la determination de la localisation de 

5 la memoire pour les requetes coherentes, les gestions des dbmaines. Le 
noyau de verificateur inclut un tableau 9610 pour les transactions en cours 
d'utilisation a Tinterieur du verificateur. Chaque entree du tableau pointe vers 
uhe instance de la classe TXNID qui represente la transmission de la 
transaction a Tinterieur du verificateur. 

10 Chaque fois qu'une requete d'entree coherente est regue par le 

verificateur 961, une structure temporaire est creee pour predire quelle 
transaction du repertoire sera utilisee comme adresse bloc et quelles seront 
les sorties predites pour le modele du circuit ASIC en test vers le circuit de 
transmission XSEqGen. Cette structure temporaire est une instance de la 

15 classe « element de collision ». Le traitement d'une transaction utilise 
toujours cette structure meme si aucune collision avec une autre transaction 
n'est detectee. 

Pour executor la prediction, I'entree de repertoire (instance de la 
classe entree de repertoire) utilisee par ce bloc est copiee et utilisee par 

20 rinstance element de collision de la classe "CollislonElement". La prediction 
de I'execution est traitee par Tusage des instances des classes "Transition" 
et des classes « action de transition » ("Transition Action"). Les Instances des 
classes « Transition » et « action de transition » font partie de la specification 
fonctionnelle contenue dans la memoire (2). Les instances de cette classe 

25 sont creees au moment de la simulation et fournissent des methodes 
fonction de la generation de transition d'etat et de la generation de requetes 
envoyees ou de reponses fournies par le verificateur. Ces methodes sont 
activees par les instances d'elements de collision de la classe 
"CollislonElement". 

30 Le fonctionnement du noyau repose sur rutilisation d'un certain 

nombre de classes qui sont utilisees, d'une part, pour decrire des ressources 
et, d'autre part, pour decrire des methodes utilisees par les Instanciations de 
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cette classe dans un objet. Cette structure sous forme de classes permet de 
realiser une plate-forme de verification facilement modifiable en instanciant 
de nouveaux objets, permettant ainsi de decrire de nouvelles procedures de 
tests ou de nouvelles reponses a des stimuli regus par de nouvelles 

5 fonctionnalites ajoutees sur le circuit. On peut ainsi aisement adapter la 
plate-forme a de nouveaux circuits developpes. 

II doit etre clair pour le lecteur que lorsqu'on utilise le terme HDL ou 
modele de type HDL, on fait reference a un langage de description d*un 
circuit integre qui est considere comme etant de plus bas niveau par rapport 

10 au langage C++ dit de haut niveau, mais ceci ne doit pas etre interprete 
limitativement car I'invention s'applique egalement a tout autre langage de 
description d'un circuit integre, tel que par exemple VHDL ou verilog ou 
encore tout autre. 

On con9oit que la presente invention peut etre mise en oeuvre selon 
15 d'autres formes specif iques, sans sortir de son domaine d'application tel que 
revendique. Par consequent, la presente description detaillee doit etre 
consideree comme etant une simple illustration d'un cas particulier dans le 
cadre de I'invention et peut done etre modifiee sans sortir du domaine defini 
par les revendications jointes. 

20 
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REVENDICATIONS 

1. Procede de verification fonctionnelle d'un modele logiciel (40) d'un 
circuit integre a la demande (ASIC), en langage de bas niveau (tel que par 
exemple de type HDL) traitant de fagon separee retablissement du modele et 

5 la mise au point des tests de verification fonctionnelle a appliquer au modele 
du circuit pour constituer une plate-forme de verification comportant les deux 
etapes suivantes : 

- constitution d'un emulateur autonome (1) de circuit obtenu en 
remplagant le modele en langage de bas niveau (de type HDL) de description 

10 physique du circuit en projet a valider, par une description abstralte de haut 
niveau (par exemple C^^) generant des structures de donnees de reponse 
confomies a la specification fonctionnelle (20) du projet en fonction des 
stimuli regus, ce mode etant dit « mode emission », 

integration du modele logiciel (40) en langage de bas niveau (de 

15 type HDL) du circuit resultant du projet dans une plate-forme de verification, 
et constitution du branchement de I'emulateur autonome (1) de circuit, 
precedemment validee, en parallele sur les interfaces du modele logiciel (40) 
du circuit, et du branchement d'un emulateur d'environnement (1 1 ,21 ,22), et 

- utilisation de cette plate-forme comme reference pour la 
20 validation des donnees de reponses emises par le modele logiciel (40) du 

circuit, ce mode etant dit « mode verification ». 

2. Procede selon la revendication 1 , dans lequel : 

• un utilisateur elabore, au moyen d'un systeme de traitement de 
donnees, la configuration de simulation autonome (1) 

25 correspondant au modele logiciel (40) de TASIC au moyen de la 

specification fonctionnelle (20), 

• Tutilisateur ecrit, a partir de la specification fonctionnelle (20), et 
memorise, dans une plate-forme de test (21 , 22, 23) de modeles de 
circuits integres, un programme (51) de test du modele (40) de 

30 I'ASIC, comportant des sequences de stimuli d'entree a fournir au 

modele logiciel (40) de I'ASIC, auxquelles la configuration de 
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simulation autonome (1) fait correspondre, en fonction de la 
specification fonctionnelle (20), des sequences de stimuli de sortie, 
• I'utilisateur relie ensemble et active la configuration de simulation 
autonome (1) et la plate-forme de test (21 , 22, 23), et 
5 • il observe les stimuli de sortie du modele de type HDL (40) de 

I'ASIC pour valider fonctionnellement I'ensemble constitue par le 
modele logiciel du circuit ASIC et le programme de test de 
validation (210), et ainsi valider le modele logiciel (40) par rapport a 
la specification fonctionnelle (20). 
10 3. Precede selon I'une des revendications 1 et 2, dans lequel, la 

configuration de simulation autonome (1) communiquant avec I'utilisateur 
pour commander I'activation de modeles, prealablement etablis et 
memorises, de sequences de stimuli d'entree definis dans un langage de 
programmation de haut niveau, et commande Tactivation de programmes 
15 associes (90) de validation progressive de sequences de test d^terminees a 
parlir des modeles. 

4. Precede selon Tune des revendications 1 a 3, dans lequel 
I'utilisateur ecrit et foumit la specification fonctionnelle (20) dans un langage 
de programmation de bas niveau, specifiant des modeles fonctionnels de 

20 circuits. 

5. Precede selon Tune des revendications 1 a 4, dans lequel 
Tutilisateur fournit la specification fonctionnelle (20) sous la forme d'un 
programme en langage de bas niveau, de modeles (de type HDL) 
fonctionnels de circuits, et d'un programme en langage de haut niveau, de 

25 modeles fonctionnels ((C++) symboliques de circuits), et il commande la 
configuration de simulation autonome (1) pour effectuer une co-simulation 
par synchronisation d'execution des deux programmes de specification. 

6. Precede selon Tune des revendications 1 a 4, dans lequel la plate- 
forme de test verifie que les reponses du modele logiciel de TASIC sent 

30 situees dans des plages de temps de reponse specifiees dans la 
specification fonctionnelle (20). 
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7. Plate-forme de verification de modele logiciel de circuit integre a la 
demande (ASIC), caracterise par le fait qu'elle comporte des moyens de 
traitement de donnees permettant a un client de selectionner des modeles de 
test engendrant des stimuli d'entree de I'ASIC, ces moyens de traitement 
5 etant agences pour lire des elements (20) de specification fonctionnelle de 
I'ASIC, et comportant des programmes (90) agences pour elaborer un 
programme de test (51) de validation fonctionnelle constitue de stimuli de 
sortie a partir des stimuli d'entree et des elements de specification 
fonctionnelle (20). 

iG 8. Plate-forme de verification selon la revendication 7, comportant une 

bibliotheque de modeles fonctionnels de blocs de circuits pour ASIC et des 
moyens de selection des modeles par un fichier de definition de la 
configuration pour constituer un modele correspondant a la specification 
fonctionnelle de I'ASIC integre a la definition de son environnement. 

15 9. Plate-forme de verification selon I'une des revendications 7 et 8, 

dans laquelle il est prevu, dans une liaison le reliant au client, deux circuits 
en serie d'adaptation de langage de programmation (11, 12) agences pour 
transformer des commandes en langage de haut niveau (C"*^"*"), utilise par le 
client, en commandes en langage de bas niveau (de type HDL), exploitables 

20 par le modele de I'ASIC, et pour, respectivement, retransformer les 
commandes en langage de bas niveau en commandes en langage de haut 
niveau. 

10. Plate-forme de verification selon une des revendications 7 a 9, 
caracterise par le fait qu'elle comporte des moyens (90, 10) d'executer ses 

25 traitements en meme temps que la simulation qu'il peut interrompre des la 
detection d'une erreur au moment meme de I'apparition de I'erreur. 

11. Plate-forme de verification selon une des revendications 7 a 10 
caracterise par le fait que les elements (20) de specification fonctionnelle 
sont constitues d'une table de verite, ou de comportement, correspondant 

30 aux fonctions des diverses parties ou divers elements de circuit fonctionnels 
du modele logiciel (40) de I'ASIC, et des plages de retard de propagation a 
respecter entre chaque entree et chaque sortie. 
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12. Plate-forme de verification selon une des revendications 7 a 11, 
caracterise par le fait qu'elle dispose d'une antememoire (962) pour 
memorlser les blocs utilises par les noeuds d'apres leur adresse et des 
moyens de gerer, pour une adresse utilisee par un ou plusieurs noeuds, un 

5 vecteur de presence avec un temoin de presence par noeud. 

13. Plate-forme de verification selon une des revendications 7 a 12, 
caracterise par le fait que les programmes (90) sont orientes objet et 
I'emulateur est structure en un ensemble de classes permettant de gerer une 
collection d'hypotheses d'execution d'une transaction sur un bloc memoire du 

10 modele logiciel, et de gerer egalement les transactions en collisions, c'est-a- 
dire utilisant concurremment un meme bloc memoire. 

14. Plate-forme de verification selon une des revendications 7 a 13 
caracterise par le fait que les algorithmes des programmes (90) de 
I'emulateur realisent les fonctions sulvantes : generation des predictions, 

15 elimination des predictions, re-ajustement de mauvaise prediction, reduction 
du nombre d'hypotheses valides et terminaison de collisions. 

15. Plate-forme de verification selon une des revendications 7 a 14 
caracterise par le fait qu'elle est utilisee en emulateur de circuit routeur, de 
circuit a antememoire ou de circuit routeur a antememoire. 

20 16. Plate-forme de verification, selon une des revendications 7 a 15, 

pour tester un modele logiciel de circuit integre a la demande (ASIC), 
caracterisee en ce qu'elle comporte un emulateur d'ASIC (1) pour 
commander un comparateur (23) prevu pour recevoir des valeurs generees 
par le modele logiciel de circuit ASIC teste, sur reception de stimuli envoyes 

25 par au moins un circuit (21) generateur de stimuli, memorisant le programme 
de test, une interface (1 1) de traduction des stimuli d'un langage elabore vers 
un langage de bas niveau correspondant a celui du modele logiciel, et des 
moyens de validation de la verification en cas de detection de collision par le 
comparateur (23). 

30 17. Plate-forme de verification selon une des revendications 7 a 16, 

caracterisee en ce que les moyens de selection de la reponse a des stimuli 
dependants de la constitution des circuits testes sont constitues d'un modele 



39 



3945/US 



elabore grace a des moyens de selection, parmi une bibliotheque, de 
modeles fonctionnels associant, a chacun des modeles, les reponses a un 
stimulus donne, le modele correspondant a la constitution du circuit a tester. 

18. Plate-forme de verification selon une des revendications 7 a 17, 
5 caracterisee en ce qu'elle comporte des moyens (7) de memorisation des 

reponses ainsi selectionnees pour constituer un modele de test (70) a 
appliquer au circuit teste lors de la reception de stimuli. 

19. Plate-forme de verification selon une des revendications 7 a 18, 
caracterisee en ce que chaque transaction est constituee, au niveau de 

10 chaque interface, d'un paquet requete et d'un ou plusieurs paquets reponses 
associes, dont les valeurs des parametres et/ou les contraintes temporelles 
d'emission des paquets peuvent etre forcees a partir du programme de test 
fonctionnel execute par Temulateur de Tenvironnement, qui traduit de fagon 
adequate Tensemble de ces parametres lors de remission des paquets aux 

15 bornes du modele logiciel du projet. 

20. Plate-forme de verification selon la revendication 14, caracterisee 
en ce que la generation des predictions est effectuee par Temuiateur du 
circuit sans avoir a prelever d'informatlons supplementaires sur le 
fonctionnement interne du circuit en projet. 
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ABREGE 
Deposant : BULL S.A. 
Inventeurs : Anne Kaszynski 
Jacques Abily 

5 La presente invention concerne un procede de verification 

fonctionnelle d'un modele logiclel (40) d'un circuit integre a la demande 
(ASIC), en langage de bas niveau (tel que par exemple de type HDL) traitant 
de fagon separee retablissement du modele et la mise au point des tests de 
verification fonctionnelle a appliquer au modele du circuit pour constituer une 
10 plate-forme de verification comportant les deux etapes suivantes : 

- constitution d'un emulateur autonome (1) de circuit obtenu en 
remplagant le modele en langage de bas niveau (de type HDL) de description 
physique du circuit en projet a valider, par une description abstraite de haut 
niveau (par exemple C"^"*^) generant des structures de donnees de reponse 

15 conformes a la specification fonctionnelle (20) du projet en fonction des 
stimuli regus, ce mode etant dit « mode emission », 

- integration du modele logiciel (40) en langage de bas niveau 
(de type HDL) du circuit resultant du projet dans une plate-forme de 
verification, et constitution du branchement de I'emulateur autonome (1) de 

20 circuit, precedemment validee, en parallele sur les interfaces du modele 
logiciel (40) du circuit, et du branchement d'un emulateur d'environnement 
(1 1,21,22), et 

- utilisation de cette plate-forme comrne reference pour la 
validation des donnees de reponses emises par le modele logiciel (40) du 

25 circuit, ce mode etant dit « mode verification ». 



Figure 1 



